User Acceptance of Agile Information Systems: A Model and Empirical Test

In response to the rapid changes in users’ requirements, a new generation of information systems (IS), namely, agile IS, has emerged. agile IS, defined as information systems developed using agile methods, are characterized by frequent upgrades with a small number of new features released periodically. The existing research on agile IS has mainly focused on the developers’ perspective with little research into end users’ responses to these agile IS. Drawing upon the tripartite model of attitude, the status quo and the omission bias theories, and the availability heuristic, we propose a model that utilizes constructs from the unified theory of acceptance and use of technology, the IS continuance model, habit, and individual differences to examine the drivers of user acceptance of agile IS. Further, we investigate not only users’ intentions to continue using the agile IS but also their intentions to use new features when they are released, which is a surrogate for the ultimate success of agile IS. Data from 477 users of an agile IS showed that users’ level of comfort with constant changes, the facilitating conditions provided, and users’ habit are predictors of both types of intentions, with users’ level of comfort with constant changes being the strongest predictor. users’ intentions to continue using agile IS are also determined by users’ satisfaction with and perceived usefulness of the past upgrades. Finally, users who are innovative are more likely to use future releases of new features. The present work fills a gap in the software engineering literature and contributes a technology acceptance model specific to agile IS, which are becoming a mainstay of companies’ IT portfolio in a fast-changing business environment. Key WorDs anD pHrases: agile methods, agile systems, availability heuristic, comfort with change, habit, information systems continuance, omission bias, personal innovativeness, status quo bias, unified theory of acceptance and use of technology (uTauT). in ToDay’s CompeTiTive business environmenT, the rapid changes in users’ requirements are creating a demand for faster software development and upgrade speed [6]. With traditional development methods, such as the waterfall method, users are required to accurately describe their needs at the beginning of a project. programmers will then follow rigid steps (e.g., analysis, design, implementation, and test) to deliver the requested features at the end of a relatively long development cycle. However, in a turbulent business environment, such projects will fail to provide the most needed software due to rapid changes in users’ requirements and the high cost of modifying software [7, 43]. This situation has led to the creation of a new generation of software development methods, namely, agile methods, such as Extreme programming or Xp, SCruM, and Crystal. agile methods refer to a collection of principles and techniques that emphasize early and continuous delivery of valuable software with embracement of constant changes in users’ requirements [19, 75]. agile methods break the long development cycle into many smaller cycles, each containing the same development steps. But the goal is not to deliver a complete system with all requested features at the end of a development cycle. In fact, there is no intention to provide the full set of features when the system is delivered to users (e.g., the Xp method calls for the development team to produce the first delivery within weeks). The system is constantly uSEr aCCEpTaNCE OF aGILE INFOrMaTION SySTEMS 237 growing by implementing only the smallest set of the most valuable functions, based on users’ input, in each round of release [7]. as a result, systems that are developed using agile methods provide only a limited set of functions when they are first introduced to users, but they will evolve periodically (e.g., monthly) based on a scheduled release cycle of features to address users’ fluid requirements. In this paper, we define agile information systems (IS) as the systems developed using agile methods. Table 1 summarizes the characteristics of agile IS as compared to nonagile IS. The existing research on agile IS has mainly focused on the technical aspects of agile methods from the developers’ perspective (e.g., [2, 15, 61]). In the studies that investigated the implementation experience of agile IS, the focus has been on the software development teams or project managers [31, 34, 44, 90] that advanced our understanding of the implementation of agile methods and the characteristics of agile IS. However, there is a lack of empirical research into the perceptions of agile IS from the users’ perspective [17]. Some scholars have noted that agile IS are often conceived and perceived differently by their constructors versus their users [32]. The phenomenon is described as a “double dream,” which is not necessarily the same for Table 1. Characteristics of agile IS Versus Nonagile IS agile IS Nonagile IS Applicable context More fluid user requirements Relatively stable user requirements Identification of user requirements Users are constantly solicited for new requirements; emphasis on adaptivity to changing environments User requirements are typically identified at the start of the development cycle, with emphasis on planning and predicting Number of development cycles Many short development cycles One long development cycle Development steps within each development cycle Rigid steps Rigid steps Functions available when system is first released System only provides a limited set of functions when first released System is expected to deliver a full set of functions when first released Goal in each development cycle Each release has limited scope, i.e., each release delivers only a few valuable functions A major release that comes with a complete set of functions Typical release frequency Frequent; typically every few weeks to every few months Infrequent; typically after a few years Example systems iPhone apps, company intranets, Web-based systems, software as a service, etc. Operational systems, enterprise resource planning, office automation systems, etc. 238 HONG, THONG, CHaSaLOW, aND DHILLON all “dreamers.” While both users and developers have their own expectations of an agile IS, their collaborative efforts may result in an artifact that only partly embodies their respective expectations. For example, the developers’ dream is to provide a few most needed functions in each round of release. users, however, may expect all functions to be provided in one release. In addition, different users may have different ideas about the most needed functions. Even for the same function, different users may hold different expectations of how and when they should be implemented. Hence, it is important to examine the agile IS phenomenon from the users’ perspective, which has not received adequate attention in the literature. The lack of empirical research into the perceptions of agile IS from the users’ perspective may also reflect an underlying assumption that users will willingly embrace the changes because they are designed to address users’ needs. This assumption may not hold, as dealing with constantly evolving agile IS is not effortless for users. The psychology literature suggests that humans have a tendency to prefer options that cause no change to the state of the world (i.e., status quo bias [63]) or require no action on their part (i.e., omission bias [58]). The status quo and the omission bias theories describe people’s reactions to changes, which are a defining characteristic of agile IS. Some researchers suggest that humans resist change because it often involves more work in the short term [39], or simply because of the uncertainty associated with the change [63]. applying this notion to the context of agile IS, users may find it difficult to deal with the frequent changes to the system interface and functions. as a result, the majority of the users, who are recipients and observers of agile IS, have to weigh the potential benefits enabled by the constant upgrades against their tendency to resist changes to the system interface and functions. Given these considerations, users’ acceptance of agile IS cannot be taken for granted, and this issue warrants in-depth research. Given the unique characteristics of agile IS and the limited understanding of users’ reactions toward agile IS, this paper aims to investigate the drivers of user acceptance of agile IS. We address the following research questions: RQ1: What are the factors that facilitate users’ willingness to use agile IS? according to the postadoption literature, users’ willingness to continue using an IS is mainly driven by a consideration of the benefits, that is, whether the system provides useful and satisfactory functions [10]. The cost to continue using an IS is considered minimal, as the learning effort has already been made during the initial adoption decision. In the case of agile IS, cost considerations are relevant throughout system usage due to the frequent changes to the system interface and features. The postadoption literature also predicts that if the current set of functions fails to satisfy users’ expectations, then users will discontinue use of the IS. However, for agile IS, users may decide to continue using the system even if the existing functions are disappointing, in anticipation that future upgrades will improve the system. Hence, there may be a different set of predictors for users’ continuance intention of agile IS. RQ2: What are the factors that make users willing to try new features enabled by frequent upgrades to agile IS? uSEr aCCEpTaNCE OF aGILE INFOrMaTION SySTEMS 239 This issue is particularly relevant for agile IS because their success ultimately depends on the capability to continuously provide new features to address users’ fluid requirements, and on the assumption that users will actually use those features as they become available. If users ignore the new features or do not feel compelled to learn how to use the new features, then the benefits of developing agile IS will be greatly compromised. Suffice to say that the answers to these research questions can provide important theoretical and practical implications about agile IS to both researchers and practitioners alike. Theoretical Background Tripartite Model of attitude We propose THaT THe TriparTiTe moDeL of aTTiTuDe proviDes a comprehensive framework for studying user acceptance of agile IS. Attitude is defined as a response to an antecedent stimulus or attitude object [13]. rooted in the trichotomy of knowing, feeling, and acting as the three main facets of human experience [45], attitude has been portrayed as a tripartite model with three major dimensions, that is, cognitive, affective (or emotional), and behavioral, in the psychology literature [25]. The cognitive dimension refers to an individual’s beliefs, thoughts, and perceptual responses about the attitude object; the affective dimension refers to an individual’s feelings, emotional responses, or gut reactions engendered by an attitude object; and the behavioral dimension reflects an individual’s evaluations of an attitude object based on past behaviors [13, 57]. The tripartite model of attitude has been empirically validated by psychologists in various social behavior contexts, including those involving change (e.g., [13, 81, 92]).